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What is a Bug? 


j^Lj.rj- * ,=:n tfcteCJ, tauft D r M^erfactlGrt- 

y ' - Webster's 


□ 


I n the beginning— 

the first computer was the size of a small building, insects and other verm,n 
QtJicklv discovered the mammoth computer to be a great place to live in 
™h and wreak havoc with the computer’s guts. When the system went 
down, scientists had to crawl around inside the giant machme and literally debug 
the computer. Yes. the first bugs reoily were bugs! 


When a Bug is a Bug 

Bugs are pesky enttem showing up in o variety of spocces such as Gameplay 
SEGA Standard, Text, and Sound bugs, plus a few more that will be discussed 
fater. These bugs are further categorized as Class A, Class B, and Class C 
hugs, depending on their severity. 

For an example, let's took at the scariest, slimiest, most sought-after bag of all - 
trie dreaded Crash bug. A Crash bug is a bug which fcrcMift*I «»< o nM« the 
. game machine for some mason, such as a frozen semen. This is called a Class 

A Gameplay bug. 

A less significant bug affecting gameplay, such as a weapon which can t be 
used, is a Class B bug. 

A graphics problem, such as a glitched background, which does not affect the 
outcome of the game would be a Class C bug. For a handy let of bug 
classification examples, refer to the Gameplay section of this report. 


When a Bug is NOT a Bug 

A mistake now Testers often perspire over is the difference between «‘ bug and a 
Comment. For example, the statement " Tms game rea% torts badt ’ ecB ™ 
grap/r/es are so boring.* is a comment, and needs to be wnttan 
A flaw deviating from what the game spec or programmer mtorded. Wrieihor or 
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not we like something in a game {winch is an opinion} is a comment (see 
Comments section of this report for more examples). 

SEGA relies on its Testers for their ideas concerning new games, and all 
comments are appreciated, A special section at the back of all test reports is 
devoted exclusively to Comments. 

If you feel you have a worthwhile bone to pick about the game, speak with the 
Game Lead or Assistant. They will tell you whether the Comment is valid, 
meaning whether it was part of the producer's intention or not, and also tell you 
the classification your comment should be written under. Gomments everyone 
agrees should be implemented In the game are usually Class A Comments, 
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How to Find a Bug 


Testing : *.. requiring maximum effort or ability." 

- Webster's 


Testing video- games sounds like a glamorous occupation, and It should bo 
enjoyable. At the same time, however, testing plays □ serious and important role 
in this company. As in all things, there is a right way and a wrong way to do it. 


Testing the SEGA Way 

The following steps should be followed when testing SEGA products' 

f, Have the following items handy before beginning: 

* A videotape. ALWAYS videotape while testing! 

* Pon/Pencil and pad. As soon as a bug occurs, write it down!: 

* The current report and lest plan /assignments. The Game Lead 
or Assistant will furnish you with both for the game you arc 
testing. 

2. Get to Know the Game - If the game you have been assigned is new 
to you, play around with it for an hour or so until you are familiar with 
how it works, what it does, and so on. 

3. Find New Bugs - Be imaginative! Nothing is too bizarre to try when 
testing. The Jess creative you are, the fewer bugs you will find 
(although a large amount of credit has to be given to being super 
logical, methodical, and analytical as well). See the Tips from the Pros 
section on the next page for some examples. 

4. Duplicate New Bugs - Attempt to duplicate all newly discovered bugs 
at least five times after finding them. Review the videotape to deduce 
the probable cause(s) of a bug, and try to uncover the shortest, easiest 
"recipe" to reproducing it. 

5. Tell the Game Lead or Assistant - Immediately report all new Glass 
A and serious Class B bugs to the Game Lcdd or Assistant. 
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6. If a Game Crashes - Press the RESET button {on the Genesis, power 
the unit down and back up for alt other devices) to see ii you can 
continue qamoplay. After checking the status of the game after you've 
reset it, always power it down. 

7. Cheat Features - Never use the cheat feature unless you are 
specifically requested to do so. If a bug occurs while in cheat mode, 
you must reproduce it with the cheat mode off to prove the bug is vatid. 
If a bug can't be reproduced without tho cheat feature, do not put it in 
the report. 

B. When in Doubt. BUG III - This cannot be stressed enough. El you 
oven remotely believe you've found a bug, discuss it with the Game 
Lead or Assistant. If you cannot speak with thorn before the end of 
your shift that day, put the alleged bug in the report, and discuss it with 
tho Game Lead or Assistant at some other time. 


Tips from the Pros 


Our group of testing gurus have come up with the following short fist of generic 
actions you should consider doing to find a bug. Of course you will think of 
others as you become familiar with testing. 

General - The following are some taps on general game testing 
procedures. Whal follows is often what makes the critical difference 
between playing a game and testing it: 

* Lfse every item, every option, and every feature, on every 
screen, even if (especially if) it has no use in that level or part of 
the game. 

* Search and use items which you don't think can or need to he 
searched or used. 

n Determine what order the user is supposed to perform the 

necessary gameplay actions, and try to perform them out of the 
expected or designated order. 

* Don't be afraid to die! Die everywhere possible. 

,, Before finishing a level, walk backwards to the beginning of the 
level and see what's up. 

- Do two things at once (like kill the boss and die at the same 
time). 

- Gel crazy with the control pad’ Try things which do not lead to 
winning the game, such as pressing the PAUSE button at 
inopportune times, or pressing buttons rapidly at different points 
in tho game. 
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- PSay with the enemies, toy with them, to determine if the game 
is too easy or loo hard. 

* In a two-player cooperative game [!■ this is supported in the 
game you are testing), try to kill your partner while he attempts 
to survive, 

- Repeat actions over and over. For example, jumping against 
the corner of a ledge a dozen times. 

, Minimize actions, such as not picking up any items, or not killing 
any enemies, or not getting any score. 

* Maximize actions, such as rolling a motor or counts., ovei, filling 
something entirely, or killing everything. 

. Try killing ail but one enemy, or nearly empty a meter or gauge. 

Collision Detection - When characters gel stuck in, disappears into, or 
walks through walls, comers, crevices, doors, the outer edges of the 
screen, clc. r then the "collision detection" is off for that object on screen. 
Here are six different collision detection tests to perform: 

■ Have the main character walk directly into all walls and/or 

* Have the main character force another character into ail walls 
and/or obstacles, 

* Move the main character to a location where it is moved by 
other objects into walls and/or obstacles. 

* Force a supporting character to a location where it is moved by 
other objects into waits and/or obstacles. 

- Position all characters so a weapon knocks them into all waits 
and/or obstacles, 

. Have the main character take d amage and rmm e d lately \while 
the character is still invulnerable or flashing) walk into objects or 

characters. 

Note" It is good practice lo oerform all of the above several times in 
" ' succession. It will probably take more than one attempt to get the 

liming nghllo uncover a bug, 

Hardware - You will usually test Genesis games with the hardware at your 
station, but frequently you will be asked to use specific hardware, 

(possibly a 6-butlon controller ora specific Genesis type}. 

When testing Game Gear tides, you must use a Game Gear, unless you 
are instructed to do otherwise, 

When testing CD titles, be sure you note which type/brand of CD dnve 
you are using. 
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How to Read and Verify Reports 


Since you've gotten this far, wc know you can absorb 'The written word '. Bui 
reading the Tester's Bible and reading a SEGA Test Report are as different as 
night and day. This chapter illustrates how to read a bug in a report, as well as 

verify them. 


The Test Report in a Nutshell 

A bug in a typical Test Report looks (ike this: 


STANDARDS 


Classification 


Number 


Qt riv _ 
in which u jg 
vr.iw fcur.c 



-Status 


i 


Fender's- BiflratS 

/ 


7 

Subsefewenl staLh^ 


OpenJs'p 

07J05J94 

VER-Tnnw 

□a»iJ94 

NOTVeR 


Curren stain!; 


This is the area where 
you will find the text — 
describing the bug. 


O^acnption 



ration dais 


VerHmr'S initials 


Category - This the category under which a bug falls (e g., File 
Identification Table, SEGA Standards, Sound, Address Error, Text, 
Gamcplay, Comments, and others specific to a game). 

Classification - All bugs arc classified as either Class A. Class B. or 
Class C, to reflect the severity of the bug. 

Number - For identification purposes, all bugs are numbered. The first 
bug in a report is numbered T, and no two bugs have the same number. 
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Initial Status - In order to keep track of the status of a bug. each is 
assigned one of the following: 


Open: 

Fixed. 

Closed: 


DUP (Duplicate): 
SPUR (Spurious): 


When a bug is found, il starts out as "Open", 

A bug which no longer occurs in the latest 
revision of the game. 

A bug which still occurs, but has been 
determined by the producer not to be an 
i mportant issue, and therefore will not be 
addressed. 

DUP is used if someone accidentally writes a 
bug which already appears in the report. 

]f a bug is oponed which is not truthfully a bug, 
it is labeled "SPUR". 


Finders initials - The initials of the Tester who found the bug. These are 
fhc assigned initials (which may differ from their true initials). 

Description - The bug itself. Lock at your Redlining manuals, they 
explain SEGA Test's bugspeak. 

Date of Rev in which Bug was Found -The date of the revision of the 
game in which bug was first found. 

Current Status - The status of a bug found on a previous revision, In the 
example on the previous page, the bug was found by “jz" on 2M5.^3. On 
3/1/93. “gf verified the bug on another revision of the game. The MOT 
al the bottom shows the bug has not boon repeated on the most 

c urrent revision in test. 

NOT VER. (Mot Verified): A bug found on a previous revision, but 

not yet seen on the current rev, 

VER, (Verified): This states that the bug was repeated 

on a future revision, the latest one's 
date is on the line beneath. 


Verification Date - This is the last revision in which the bug was verified. 


Verifier's initials - The person who verified the bug, 

Note: The initials following a DUP are those of the Game Lead and the 
initials following a fixed binary bug are those of the Tester who 
thinks the bug is fixed. 
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How to Verify a Report 

To verify a report means to try to reproduce all bugs having a NOi VER. status. 
When doing this, at least ten attempts should be made on each NOT VER. hug. 

It is extremely im portant tor you to keep track of all attempts by using the old tick 
maTkmethod (I, It, HI. etc,)- After each try mark a little “tick" next to the bug on 
which you are working. 

Note - Only those attempts which completely fulfill the conditions described in the 
bug, receive tick marks. If you try to duplicate a bug. but leave some 
action out, it dees not count as a tick mark. 

Your Test Report must be given to the Game Load or Assistant on your shift at 
ihe end of your shift. All tick marks are entered into ihe database to help the 
Game Lead or Assistant determine the status of testing on his/her game. Wnttng 
tick marks not only helps you keep track of your attempts, but also proves to the 
skeptical Game Lead or Assistant you are actually doing your assignment. 
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How to Write a Bug 

Okay, it’s lime tor the fun part. Everyone needs to pay close attention now. The 
art of good bug writing is a serious subject a* SEGA. Much time and effort has 
been out forth to come up with the right formula for writing clear, concise hugs 
people here, as well as in Japan, can understand immediately. 

And now, welcome to the world of bug writing,- 


Elements of Written Bugs 

Almost all bugs are written in the following form: 

(frequency), (location), (rnooe s/s e tttngs) r (it/when). (causal events A 
(buggy events), (correct events) if (causal events). 

Building Blocks - The following is a list ot all the possible elements which 
contribute toward describing bugs. Note not every item appears in every 
bug, as some bugs will only contain a partial sampling of the list. 

Frequency - This statement describes the occurrence rale of the bug. 

The possible Frequency statements are: 

Once: Use if the bug has only occurred one time in 

the lifetime of the game. 

Twice: Use if the bug has occurred two times in the 

lifetime of the game. 

Three times: Use if the bug has occurred throe limes in 
the lifetime of the game. 

Occasionally: Use if the bug has occurred tour or more 

times in the irfetime of the game, but occurs 
less than 50% of the time, 

Frequently: Use if the bug oocurs more than 50% but 
less than 100% of the time. 

(None): It the bug occurs 100% of the time, no 

frequency statement is used. 

Location - Where ths bug occurs. This includes any screen or level 
descriptor, followed by the specific point in the gameplay map (or on the 
specified screen) at which the bug occurs. It the bug occurs anywhere in 
the game, independent of Location, state throughout the game , 

Modes - Any mods setting significant to creating the bug, Use the^word 
to indicate the mode. For example; “‘...in two-player mode,..*, \.Jn 
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one-player Tournament Mote,..?, etc. IF a bug occurs in one- and two- 
player m cde, useT.. in one- and two-plcycr modes, „ 

Settings - Options, settings, time remaining, etc. Use the word wittf to 
indicate the setting, as in “...with f,ve seconds remaining in the round,... , 
with Background Music set to OFF,..*, etc. if the bug occurs with any 
combination "of settings, no settings indication is used, unless specifically 
requested by the Game Lead and/or Assistant. 

^ 11 " g r "When :r - Bugs occurring 100% of the time use tha word iT bugs 
with any other frequency use the word "wherf , 

Causal Event(s) ■ This is a chronological list otthe events which cause 
the bug. it no actions are required to cause the hug, no listing of Causal 
Events Is used. 

Buggy Event(s) - This is a chronological list of the actual events of the 
bug, beginning with the first Buggy Event. 

^Must” Statement - This is an indication of what is supposed to happen 
in the aerterat case followed by a generalized restatement of the causal 
events, (no “Must* statement is used in graphic ■■ or Glitch - bugs). 


Reporting Verb Tense Bugs 

Bugs with a frequency of Once, Twice, or Three Times use the past tense for all 
verns Bugs with all other frequencies (that being Occasionally or greater) use 
the ore sent tense for all verbs. The rationale behind this ruleis bugs with a rate 
of occasionally or more can be recreated, and can therefore be written ao <> u ^' n 
the present tense. On the other hand, bugs occurring three times or loss cannot 
necessarily be recreated, and therefore can only be described in tenns ot the 

past tenso. 

Summary of Frequency Effect on Bug Construction - The frequency of 
the bug affects the Frequency statement, the If/When statement, and the 
Verb Tense of the bug. Use the following chart to quickly find trie- 
appropriate way to construct a bug based on its frequency. 
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How Often bud appears 

Frequency 

Statement 

If/When 

Verb Tense 

One time (X=1) 

Once 

When 

Past 

Two times (X - 2) 

Twice 

When 

Past 

Three limes (X - 3) 

Three times 

When 

Past 

More than three times,, 

Occasionally 

When 

Present 

but less than 50% of the 
time (3 times < X < 50%) 
More than 50%, but 

Frequently 

When 

Present 

less than 100% of the 
lime {50% < X < 100%) 
Each and every time 

(None) 

If 

Present 

(X= 100%) 





Reporting Lists of Events 

Jf a bug requires a string four or more long and wordy events to occur, or if fou: 
or more tong and wordy buggy events occur as the resull of an action or set of 
actions, it may be necessary to write a List bug. For example: 

tn Mystic Cave, Act h or foe Sedge above the shield power-up, if: 

}) Sonic stands on the Sedge, 

2} the ledge corpses, 

3} Sonic collects the shield power-up below the Sedge, 

4) grabs the vine, 

5) jumps off the vine, and 

6) Sands in the bottom of the pit, 

the vine does not return to the bottom of the weit r and Sonic is unabSe to 
exit the pit until he dies and restarts the level, or the timer runs out. The 
vine must return to the bottom of the well. 


Different Bug Categories 

Test reports are broken dawn into multiple categories. The most com man iy used 
categories are listed on the following page: 


- 


* Advisory 


Fils Identification lable 
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* SEGA Legal Department 

* SEGA Standards 
- Options 

■*■ Sound 
. Commentary 

* Gameplay 


Peripherals Standards 
Address Errors 
Text 

Statistics 

Manual 

Comments 


The following sections explain how to write bugs in each category- Examples of 
each are also included- Think of a well-written bug as a recipe, gluing step-by- 
step instructions on how to make the bug- Keep in mind programmers (as well 
as other Testers) must be able lo recreate these bugs using only youir 
instructions. 


Classifications of Gameplay Bugs 

Gameplay bugs generally comprise at least half the bugs in a report, and are 
classified as Class A, Class B, or Class C bugs. 

Class A Gameplay Bugs (Crash Bugs) - Bugs which describe any of the 
following occurrences are classified as Glass A Gameplay bugs: 

* Force the user to reset the game, 

- Lose a saved game. 

- Force the user to wart for more than 2 minutes to resume 
gameplay. 

- Force the user to use a Continue. 

* Make the user unable to complete the game as a consequence 
□f periomiing some required action. 

Depending on the type of bug you are describing, use one of the following 
must statements for Class A Gameplay bugs: 

Ef the game freezes or locks up but normal gameplay resumes after 
pressing the RESET button, write “At this point r the system must be 
reset,”'. 


• If the game freezes, and the system must he powered down to 
restart gameplay, write “At this point the system must be 
pow&fsd down" 

* If the user is forced to wait two or more minutes to resume 
normal gameplay, or is unable to continue gameplay past a 
certain point in the game {e.g, f the first level has no usable 
exits, and the users character Is unabic to advance to the next 
t eve ^ n simply describe what must (or must not) happen. 
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The following is an example of a Class A bug which occurs every time. 
Note how no frequency is written explicitly: 


!n the Kazalt Dungeon, in the room above the Flamegu&rd Boots, if 
Ryie fakes damage and immediately walks into the yellow platform. 
Ryie tails into the hole beneath the platform, becomes trapped, a <. d 
cannot be returned to gameplay. Ryle must not fall through 
platforms, 

The following is an example of a Class A bog which does not occur every 
time. The user has tried, but is unable to repeat the bug at will. (Note the 
word “wher? is substituted for the word “jT}: 

Occasionally throughout the game, when Sonic collects 1DO rings, 
the game freezes on a black screen. At this point, the system must 
he powered down. 

Here's an example of a Class A bug in which the game does not crash, 
but the user must wait two minutes to resume gameplay. Also, note the 
user could only find the bug twice, so the bug is written in the past tense: 

Twice, in Wee Willy Wonka's Chocolate Factory, at the beginning 
of the level, when Charlie removed the Aspic Shoes and walked 
into the Hull of Minors, Charlie became stuck for two minutes until 
the leva! timed out and Charlie restarted the level. Charlie must not 
become stuck in the Hall of Mirrors. 

Here's an example of a Class A bug where the user can still engage in 
gameplay to a limited degree, but must wait more than two minutes to 
advance in the game (if the user waits less than two minutes, it is a Class 

B bug): 

j n Excalibuhs Lighthouse, if Nightcrawicr teieports to the special 
visors, and the user changes characters, the new character rs 
unable to advance through the blocked passages to finish the level 
until ten minutes pass, an enemy appears, the enemy kills the now 
character, and the character restarts the level. Ail characters must 

be able to complete levels. 

Be sure to include any peculiarities associated with the crash bug, like 
“The music continues to play .: for example. 

Twice, in The Skyscraper, in two-pfayer mode, with the sound 
effects OFF. when the Slime Ball appeared, and Egon used the 
Hypcrpl^mic Ultrasonic Megadeath Slingshot ; the game froze on a 
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black screen. The music continued to play. At this point, the 
system had to be powered down. 

Class B Gamepiay Bugs- ■ Anything directly affecting or hindering 
qameplay: resulting in features not wooing property 1 items not tabulating 
correctly, or characters or enemies no! taking damage, etc- is classified as 
a Class B Gamepiay bug. Unlike most Class A bugs, the Must 
statement fora Class B Gamepiay bug emphasizes what must happen for 
the game to work correctly. The following are some examples. 

Occasionally, in Elemental Air 1, when Chakan jumps straight up 
and touches a flying enemy, Chakan does not take damage. 

Chakan must take damage if he touches an enemy. 

Throughout the game, if Ariel collects seven Keys , enters a Shop, 
and buys a Key, Ariel's Key total decreases to one The game 
must keep accurate track ot the number of items in Ariel's 
possession. 

Class C Gamepiay Bugs - Any and all graphic glitches (which do not 
adversely affect qamcpfcay), and graphic inconsistencies are classified as 
Class C bugs (an inconsistency is any graphic element of the game which, 
while not imoroperiy displayed, does not correspond to the conditions 
established by the game' seethe example below). Again, glitch bugs do 
not require a “Musf statement. 

Note: If the entire screen becomes covered with glitches (known as 

"corrupting"), and the user is unable to complete the current level 
because he is unable to discern objects on the screen, this 
becomes a Class A Gamepiay bug, and should be written up as 

such. 

If the user has difficulty, but is still able to complete the level despite the 
corrupted graphics (e g., only the background screen is corrupted, or the 
corrupted area can be scrolled offscreen), this should bo written up as a 
Class B Gamepiay bug. 

Gl itches - The following is an example of a typical bug report discussing a 
graphic glitch: 

At Chen Lu r s if the user examines the Vidphone, places the cursor 
over the exit and presses the B button, the Inventory Icon glitches. 

At Chen Lu’s, if the user examines Ihc Vidphonc, places the cursor 
over the exit, and oresscs the B button, the inventory Icon appears 
glitched until the user exits Chun Lu's, accesses the items 
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Inventory Screen, selects the Candy Bar, exits the Items inventory 

Screen, nncf presses the C button six times. 

Inconsistency - The following is an example of an Inconsistency bug: 

Throughout the game, cmcmids ere red. Emeralds must appear 
green. 

Text - Extra caution must be taken when writing Text bugs. Often the 
developers who fix the text bugs do not speak English as a first language; 
they may not even speak English at alt! It wo send a confusing or 
misleading text bug, a new mistake wiEI no doubt show up in the next 
revision of the game and the cycie begins all over again. 

Formats - Two different formats are used when writing Text bugs; 

Action-related text bugs - If the incorrect or poorly worded text 
appears as the direct resuit of a certain action or set of actions, use 
the following format: 

(Frequency), (location), (in two-player mode, if applicable), 
(settings), (iffwhen), (who docs what), “the following text 
appears” (if the begged fexT is only part of the total text 
which appears 3$ a result of the action), or, The text reads' 1 
if the bugged text represents the entire text which appears 
as a resist! of the user’s actions): 

"The incorrect text" 

Change to: 

"The correct text," 

Replace “incorrect " wish “correct”. 

Note: The last four lines of the above example is called the 
Reiteration Statement. This statement restates (and 
clarifies) exactly what is to be chanced in the text. 
Punctuation of a reiteration statement which is not 
part of the bugged text is always placed outside the 
bugged text, 

For example, look at the following Reiteration Statement; 

Replace the word '‘ARGD" with the word “XYZ". 

The period at the end of the statement must go outside the 
quotation marks surrounding the word ~XYZ'. This is to avoid 
confusing the punctuation in the Reiteration Statement with the 
punctuation in the bugged text. 
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If the required change results in the replacement of an entire 
sentence, phrase or paragraph, use the following format for the 
Reiteration Statement: 

Replace the first (sentence/phrase/paragraph/set of text) 
with the second (sentence/phrase/paragraph/set of text). 

An example of this would be: 

In The Apartment, Part 2, if Sigourney opens the refrigerator 
and searches, the following text appears: 

‘The graves are pretty messed up. Looks like Dr. 
Frank N. Stein’s been at it again!’’ 

Change to: 

“Ugh! What a mess! Looks like it’s McDonald’s for 
me tonight...” 

Replace the first text with the second text. 

Non-Action-related Text Bugs - If the faulty text is not directly 
related to the user’s actions, such as a text bug which appears in 
the ending credits, no If/Then statement is necessary: 

(Location), the text (under the heading/for the item/etc.) 
reads: 

‘The incorrect text.” 

Change to: 

‘The correct text.” 

Replace “the incorrect text" with “the correct text”. 

Another example of this would be: 

On the Level 11ntro Screen, the text reads: 

“Get Ready to Beggin Level 1.” 

Change to: 

“Get Ready to Begin Level 1.” 

Delete the first letter “g” in the word “Beggin”. 
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In addition, if the bugged text appears in the game as all caps, 
write the text bug in all caps. For example: 

In the Ending Credits, the text under the heading LEAD 
TESTER reads: 

•GOD” 

Change to: 

“Christopher Cutliff the III, Esquire” 

Replace the word “GOD” with the text “Christopher Cutliff the 
III, Esquire”. 


Classifications of Text Bugs 

All Text bugs are Class A or Class B Text Bugs. 

Class A Text Bugs - These are text errors which must be changed. Any 
misspelled or incorrectly punctuated text (including spacing), text which is 
grammatically incorrect, gives incorrect information, appears in the wrong 
place, or which does not make any sense in the context of the game 
constitutes a Class A Text Bug. 

For example, the following is a bug about text which contains incorrect 
information: 

In The Emerald City, Part 3, if Dorothy defeats the Wicked Witch of 
the West and talks to Glinda, Glinda’s text reads: 

“Now, my dear; All you have to do is press and hold down 
on the D-pad, and tap the C button three times, and you 
shall be home again.” 

Change to: 

“Now, my dear; All you have to do is press and hold down 
on the D-pad, and tap the B button three times, and you 
shall be home again.” 

Replace the letter “C” with the letter “B”. 

The following bug documents misspelled and incorrectly punctuated text: 

In The Tin Soldier, the File text for Murray Hollander reads: 

“mr. Hollander was once an associate of Moriarity.” 

Change to: 

“Mr. Hollander was once an associate of Moriarty.” 
Capitalize the letter “m” in the word “mr.”, and delete the second “i” 
in the word “Moriarity”. 
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Class B Text Bugs - Class B is reserved for text which is technically 
correct, but reads poorly, or is out of place with the rest of the game. This 
includes stylistic changes which are merited by the ambiance or setting of 
the game. For example, if the text "Radical, dude! appears in an RPG 
set in Britain in the 13th century, this is a stylistic issue which merits 
change. 

The following are some examples of Class B Text Bugs: 

Reads Poorly - The following is an example of a bug reporting text 
which reads poorly: 

If Sonic completes a stage, the following text appears: 

“SONIC GOT THROUGH ACT 1” 

Change to: 

"SONIC COMPLETED ACT 1” 

Replace the text "GOT THROUGH” with the word 
"COMPLETED ” 

Stylistic Anomaly * The following is an example of a bug which 
reports a differentiation in the style used in the text of the game: 

In The Slums, Part 1, if Akira defeats Mothra, and talks to 
Sluggo the Idiot Boy, Sluggo’s text reads: 

"Might I humbly request a repetition of your 
felicitous salutation?” 

Change to: 

"Duh...huh?” 

Replace the first text with the second text. 

In the case of a proposed text change which is neither required by 
the rules of grammar, spelling, etc., nor merited by the internal 
structure or setting of the game, see the Game Lead before writing 
it up as an actual bug. 

Note: Vulqar or offensive text is written up as a Class A Advisory bug. 
For more information, see the Game Contents section of the 
Advisory Bugs Checklist in the Tester’s Bible. 
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Reporting Sound Bugs 

Sound bugs are written exactly like Gameplay bugs, and are classified as either 
Class A or Class B bugs (Class C Sound Bugs are written as Comments; for 
more information, see the Comments section of this report). 

Class A Sound Bugs - Class A Sound bugs describe any readily 
noticeable noise which continues through a level or until the end of the 
game, or any sound which is intensely loud and/or irritating. In the event 
the sound which repeats or corrupts is part of a commentary track (e.g., 
the commentator in a football game), write the bug up as a Class A 
Commentary bug (see the Commentary section of this report). For 
example: 

In Level 1, if Boy Gorge presses the light switch, a loud, static like 
noise plays until the level ends. The correct sound effect must play 
if Boy Gorge presses the light switch. 

Class B Sound Bugs - These are bugs which report missing or 
inconsistent sound effects, sound effects out of sync with gameplay 
animation, or garbled or faulty sound reproduction. 

Here are some examples: 

Frequently, in the Vents, when Dallas fires the Flame-thrower, the 
background music stops until the sound effect for the Flame¬ 
thrower ends. The background music must play continuously. 

Throughout the game, in the Bathroom, at elapsed time 15:40, if 
the user switches back and forth between the Bathroom and the 
Driveway, the radio conversation between Kelly and Mike plays 
approximately three seconds out of sync with the video sequence. 
All sound and action must be synchronized. 

If a character begins to announce the Access Color Code change, 
and the user presses the C button, the Access Code 
announcement plays garbled. Speech must play normally. 

Class C Sound Bugs - There are no Class C Sound Bugs; if the 
description of a particular sound problem does not match the description 
for a Class A or Class B Sound Bug, it is written as a Comment (see the 
Comments section of this report). 
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Reporting Commentary/Dialog Bugs 

Commentary is any running dialogue which describes gameplay. The 
Commentary category generally appears in sports games. Commentary bugs 
are classified as either Class A or Class B. 

Class A Commentary/Dialog Bugs - Class A Commentary Bugs are 
those in which the commentator repeats for and excessive period of time, 
and are written much like sound Class A bugs. 

Class B Commentary/Dialog Bugs - Class B Commentary Bugs are 
missing commentaries, inaccurate commentary, or commentary which is 
garbled or distorted. The following is an example of this type of bug: 

Occasionally, when Steve Young passes the ball, the commentary 
states, ‘‘And Joe drops back to pass”. Commentary must accurately 
reflect gameplay. 


Reporting Address Error Bugs 

All Address Error Bugs (Super Target Address Checker [STarget] and Internal 
Address Errors) are classified as Class A bugs. For a full description of the 
STarget Hardware, see the full Address Checker section of this report. 

Address Checker bugs are formatted almost exactly the same as Gameplay 
bugs, except a data table appears at the end of the bug. Use one of the 
following three formats, depending on whether or not the data varies: 

One Address, No Variation in Data - The following is an example of the 
text of a bug report for this error: 

(Frequency), (Location), (if/when), (circumstances), the following 
address error (occurs/occurred): 

ADDRESS DATA PC UGHIS 

XXXXXX XXXX XXXXXX XXX 

One Bug, Two to Three Different Data - If the ADDRESS, PC or DATA 
information varies, but the ADDRESS is the same, use the following 
format: 
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ADDRESS 

DATA 

PC 

LIGHTS 

xxxxxx 

XXXX 

or 

XXXXXX 

XXX 

xxxxxx 

XXXX 

or 

xxxxxx 

XXX 

xxxxxx 

XXXX 

xxxxxx 

XXX 


One Bug, Four or More Variations of Data - If the exact same set of 
actions or circumstances brings about four or more address errors with 
different addresses, use the following format: 

(Frequency), (Location), (if/when), (circumstances), the following 
address error (occurs/occurred): 


ADDRESS 

DATA 

XXXXXX 

XXXX 

xxxxxx 

XXXX 

xxxxxx 

XXXX 

(varies) 

(varies) 


PC 

LIGHTS 

XXXXXX 

XXX 

or 

XXXXXX 

XXX 

or 

XXXXXX 

XXX 

(varies) 

(varies) 


This means put "varies" in the columns when the data does vary and put 
the constant data in the columns which are consistent. 

Each address error type is followed by one of the below: 

After the (address error/string of address errors) (is/was) cleared, 
normal gameplay (continues/continued). 

or 

After the (address error/string of address errors) (is/was) cleared, 
the game (freezes/froze) on a (black/white/glitched/etc.) screen. 

or 

After the (address error/string of address errors) (is/was) cleared, 
the game (reset/resets) to the (SEGA logo/Title Screen). 

or 

The string of address errors (continues/continued) indefinitely. 


Reporting Statistics Bugs 
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For the most part, Statistics bugs are relegated to the realm of sports games, 
and fall into one of the following two categories: 

• Standing statistics for players in the game’s roster, or 

• Game-generated statistics. 

All Statistics bugs are Class A, use the following formats when writing them: 

Class A Statistics Bugs - If the game features an official license (e.g., 
NBA, NFL, WWF, etc.), or is based on an actual athlete or team, any 
incorrect player or team statistic must be bugged. Because most statistics 
bugs appear in the game as text, most Statistics bugs use the Text bug 
format. For example: 

On Mike Tyson’s Stats Screen, the “Win/Loss Record” statistic 
reads: 

"39 - 2” 

Change to: 

"39-1” 

Replace the number “2” with the number “1”. 

Another form of a Statistics bug is any incorrect game-generated statistic. 
For most game-generated Statistics bugs, use the standard Gameplay 
bug format. Some examples are: 

Frequently, in HUMAN vs. HUMAN mode, when player one throws 
200+ punches, and player two does not throw any punches, the 
user’s Punches Thrown statistic on the Round Stats Screen reads 
“1”. The Punches Thrown statistic must accurately reflect 
gameplay. 

Frequently, in HUMAN vs. CPU mode, when the user’s team 
scores more than one touchdown, the user’s Touchdowns statistic 
on the Half-time Stats Screen reads “1”. The Touchdowns 
statistics must accurately reflect gameplay. 

Finally, if glitches appear on the Statistics Screen, write the bug as a 
Gameplay C bug. For example: 

Occasionally, in two-player mode, with sound effects off, when the 
game goes into overtime, ends, and the Game Statistics Screen 
appears, the bottom half of the screen appears covered with 
vertical bands of blue and white sprites. 

Note : As with all Class C Gameplay glitching bugs, no Must statement is 
included. 
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Reporting Advisory Bugs 

Advisory bugs may be broken down into two categories; Game Content and 
Gameplay. 

Game Content or Gameplay - For an Advisory bug related to game 
content or gameplay, use the appropriate Gameplay bug format, and 
remember there is no Must statement for Advisory bugs. For example: 

In the Game Credits, Candy Kane is listed as a “SUCCUBUS” (a 
female demon who assumes human form to have sex with men). 

SEGA Standards - Your Game Lead may ask you to fill out a SEGA 
Standards checklist. Each SEGA Standard is classified as either a Class 
A or Class B bug. Check the SEGA Standards checklist for a 
comprehensive listing of the SEGA Standards bugs and their 
classifications. Use one of the following guidelines below to write the 
bugs: 


Missing Features - For a SEGA Standards bug related to the lack 
of a particular feature or screen, use one of the following formats: 

The game does not contain a (Name of screen/feature/etc.). 
According to SEGA Standards, the (game or name of 
screen) must contain a (name of screen/feature/etc.). 

or 

(Frequency), (location), (settings), (if/when) (causal events), 
(buggy events)...According to SEGA Standards, (correct 
events) if (causal events). 

Some more examples are: 

The game does not contain an Options Screen. According 
to SEGA Standards, the game must contain an Options 
Screen. 

On the Title Screen, if the user presses the A, B, C, and 
START buttons simultaneously, the game remains 
unaffected. According to SEGA Standards, the game must 
reset to the CD Control Panel if the user performs a soft 
reset on the Title Screen. 
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Note : Avoid the construction ‘There is no...” when writing SEGA 
Standard bugs at ail costs. 

Copyright Issues - All SEGA Standards violations which represent 
potential legal issues are written up as Class A SOA Legal 
Department Bugs. 

SOA Legal Department - Anything which appears in the game, 
from names of characters to sprite images to overall game 
mechanics, which borrows directly or even heavily from some other 
copyrighted or trademarked source must be written up as a Class A 
SOA Legal Department bug. SOA Legal Department bugs fall into 
one of the following two types: 

1. Definite infringements 

2. Potential infringements 

All SOA Legal Department bugs are written up as Class A bugs, 
and use one of the following two formats: 

Definite Infringements - In the case where the Legal Department 
says, the game borrows from, names, or depicts material which is 
both obviously recognizable and known to be copyrighted or 
trademarked, use the following format: 

(Frequency), (location), (if/when)(causal events), (the legal 
thing appears). According to SOA’s Legal Department, the 
game must be free of (copyright/trademark) infringements. 

Another example would be: 

In The Morgue, if Sonic becomes a flesh-eating zombie, the 
text makes reference to Quaker Oatmeal, which is a 
trademarked brand of cereal. According to SOA’s Legal 
Department, the game must be free of trademark 
infringements. 

Potential Infringements - In the case of a potential infringement, 
either: 

1. The alleged source material is known to be legally protected, 
but it is uncertain whether the game is actually “borrowing” 
the material from this source, or 

2. The legal status of the “borrowed” material is unknown. 
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For potential copyright/trademark infringements, use one of the 
following formats to write up the bug: 

Trademarked/Copyrighted Source, Questionable Borrowing - A 

good example of this type of bug would be in the following format: 

(Frequency), (location), (it/when)(causal events) (a (what?) 
appears/the text makes reference to (what?)/the (what?) 
is/are similar to (what?)), which may be an infringement of 
((what?) - i.e., the reason for the potential infringement). 
According to SOA’s Legal Department, the game must be 
free of potential infringements of legally protected 
(copyrights/trademarks). 

Some more examples would be: 

In The Sewers, at the right end of the level, a silhouetted 
shark appears on a red-and-yellow poster with the caption 
‘Triassic Shark”, which may be an infringement of the 
Jurassic Park trademark. According to SOA’s Legal 
Department, the game must be free of potential 
infringements of legally protected trademarks. 

The gameplay is similar to that in Master of Monsters , which 
has hex battle maps, summoned monsters, class advances, 
spell casting, and conquerable castles and towns, which 
may be an infringement of Acclaim’s copyrighted game 
engine. According to SOA’s Legal Department, the game 
must be free of potential infringements of legally protected 
copyrights. 

Obvious or Questionable Borrowing, Trademark/Copyright 
Status Unknown - A good example of this type of bug would be in 
the following format: 

(Frequency), (location), (if/when)(causal events), (the 
(what/who?) that/who appear(s) is/are similar to (what?)), 
which may be a legally protected (copyright/trademark). 
According to SEGA’s Legal Department, the game must be 
free of potential (copyrights/trademarks) infringements. 

The following are good examples of this type of bug: 

In The Mad Forest, immediately to the right of the second 
tree, if Ellis jumps in place three times, the rabbit who 
appears says, “I’m late, I’m late!” is very similar to the rabbit 
in the Lewis Carrol novel, Through the Looking GJass , which 
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may be a legally protected copyright According to SOA’s 
Legal Department, the game must be free of potential 
copyright infringements. 

File Identification Table - All File Identification Table bugs are 
Class A bugs, and are written similar to Text bugs: 

In the File Identification Table, the (field name) line reads: 

"the incorrect data" 

Change to: 

“the correct data" 

Comments - Comments are meant to document ways in which you 
think the game could be improved. In effect, Comments are 
suggestions in the form of a bug, and are generally written up the 
same way. 

Formats - Most Comments fall into one of two types: 

• Anything which occurs as a result of gameplay, which 
you feel should occur in a different manner. 

• Any feature, designed as a part of the game, which 
you feel should be omitted or changed, or a missing 
feature which you feel should be implemented in the 
game. 

For Comments in which specific gameplay actions result in a 
consequence you feel should be changed, use the following format: 

(Frequency), (location), (mode), (settings), (if/when) (causal 
events), (poor design issue) (should statement). 

The Should statement in a Comment is written almost exactly like 
the Must statement in a Gameplay bug, except the word “should 1 is 
used in place of the word “must'. In addition, the Should statement 
is generally prefaced by some sort of reason for making the 
change, some selling point, such as “To balance gameplay,... or 
“To enhance realism,...”, etc. The following are some examples. 
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In the Docks, if the user’s character jumps over each enemy 
ninja, rolls under the tiger, and walks to the end of the level, 
the game advances to the next level. To balance gameplay, 
the user’s character should have to fight a given number of 
enemies to complete the level. 

Frequently, in Gestalt, in two-player mode, when Ryle hits 
an enemy with a fully charged Fire Sword, the enemy’s 
flaming damage animation briefly appears; and disappears. 
To enhance the game’s graphic appeal, the flaming damage 
animation should remain on the screen for at least one full 
second. 

Missing or Deletable Features - For Comments which relate to missing 
features, use the following format: 

(Frequency), (location), the (game, character, item, etc.) 
can/cannot only (do what?), or has no/does not contain (what?). 

To (balance/enhance gameplay), (the character, item, etc.) should 
(be able to do/have/contain what?). 

The following are some examples: 

In a passing play, the user’s quarterback can only throw a standard 
pass. To make the game more realistic, the user’s quarterback 
should have the option to throw a lob or a bullet. 

In the final fight with the Flying Witch, Dorothy has no projectile 
weapons. To make the fight with the Flying Witch fair, Dorothy 
should have projectile weapons. 

Do not use the construction, “ Currently; the game has no...” Obviously, if 
we are testing a current revision of a game, the desired feature is 
“ currently ’ in the game. Also, if appropriate, try to include a comparison to 
a best selling game which has the suggested feature; this will give the 
Comment greater validity. For example: 

The user is unable to access status information outside of battle or 
Headquarters. To enhance gameplay, the user should be able to 
access status information at any time, as in Shining in the 
Darkness. 

Classification of Comments - The Game Lead will review your 
Comments, verify the majority of the Test Department agrees the 
Comments represent viable issues, and decide what the relative 
importance of each comment is. Based on the number of A, B, and C 
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Comments already in the report and the popularity of the comment, the 
Game Lead or Assistant will classify your Comments. The Game Lead or 
Assistant should generally attempt to balance the number of comments so 
there are less Class A Comments than Class B Comments. 


Some Things to Avoid (Bug Traps!) 

Here are a few things to avoid when writing bugs: 

Combining Bugs - Only one item should appear in each bug. For 
example, the following is a bug written incorrectly: 

If the user's character selects the Saw Hand and LaunchHand 
power-ups, gameplay remains unaffected. Both the Saw Hand and 
Launch Hand must work. 

The following is an example of this same bug, written correctly as two 
different bugs: 

If the user's character selects the Saw Hand power-up, gameplay 
remains unaffected. The Saw Hand power-up must work. 

If the user's character selects the Launch Hand power-up, 
gameplay remains unaffected. The Launch Hand power-up must 
work. 


Unclear Words - Avoid the following: 


“ w ni ’ Use “fa//s” instead of “will fall ’ 

“/s” Use “jumpd’ instead of “is jumpingf 

‘T or “you” Use “useT or “the useT instead 
Contractions Use “do not’ instead of “don’t’ 


Unclear Phrases - Avoid using phrases such as: 


Instead of 

"Stands on an invisible platform" 
"Goes through solid objects" 

" Pushed the A button" 

"Pressed the PAUSE button" 

"There is..." 

" There must be..." 


Use 

"Stands in midair" 

"Passes through solid objects" 
"Pressed the A button" 
“Paused the game" 
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Terminoloav Conventions 


The following is a list of the most frequently used words in test reports. Please 
refer to this list as a guideline for spelling, punctuation, and correct word usage 

when writing any bug. 


Word 

1 Button 

2 Button 
A button 


Alpha 

B button 

Beta 
Boss 
Button 1 
Button 2 
buttons 
C button 

Control pad 
D-pad 


Demo Mode 

Difficulty Option 
Difficulty Setting 
File Identification Table 

In/On 

Level 


Main Boss 
Midair 


Comments 

See “Button 1”. 

See “Button 2”. 

This is the button labeled with an “A” on the controller. Bug report 
format: Button name in caps, “ button" in lower case. Don’t use 
“Button A." 

This is when a game is in a pre-beta state of completion. There may 
be no Title Screen, and/or all major game features may not yet be 
fully implemented. 

This is the button labeled with a “B” on the controller. Bug report 
format: Button name in caps, "button" in lower case. Don’t use 
“Button B 

All major game features (sound, Title Screen, and the Options 
screen), now appear in the game. 

This is the finale to a level or section of a game. Format: Never 
capitalized when used alone (see mini-boss, main boss, sub-boss) 
This is the button labeled with an “1” on the controller for the SEGA 
Game Gear. Bug report format: "The 1 Button." 

This is the button labeled with an “2” on the controller for the SEGA 
Game Gear. Bug report format: "The 2 Button. 

This term is not capitalized; button names are in all caps. For 
example: “START button”, “RESET button”, “A/B/C button” 

This is the button labeled with a “C” on the controller. Bug report 
format: Button name in caps, "button" in lower case. Don’t use 
"Button C." 

See “D-pad". 

This is the directional pad on the controller. Bug report format: 

Capital “D”, a hyphen, and a lowercase “pad”. Use instead of "D- 
button." 

This is what is displayed if no action is taken by the user at the start 
of a game. Bug report format: Initial caps for both words. 

Bug report format: Initial caps for both words. 

Bug report format: Initial caps for both words. 

This information is obtained by the SEGA Tech Department and 
provides information identifying the platform on which each game 
was written to operate. Bug report format: Initial caps for all words. 
Do not use these terms interchangeably. Bug report format :"...in the 
levet', "...in the stage", “...in the round', but “...on the screen" 

This is the point in the game where the user is in the game. Bug 
report format: Capitalize when referring to a specific level. Numbers 
must be typed as they appear in the game (letters or digits): Level 1, 

Level I, Level One. 

This is the major enemy at the end of a Level. Bug report format: 
Two words, never capitalized. 

Bug report format: One word. 
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Mini-boss 

Mid-boss 

NOT VER. 

Not Verified 
Offscreen 
On-screen 
On/In 

Onscreen 

One-piayer 
Option Menu 
Player 
Power Stick 
Power up 


Power-up 


Presses the button 
RESET button 


Round 


Screen Names 
SEGA 

SEGA Logo 
SEGA Standards 
Stage 


START button 

Sub-boss 
Title Screen 

Two-player 

User 

Verified 

VER. 


This is the larger enemy at the end of a smaller section. Bug report 
format: Hyphenated, never capitalized. 

This is the larger enemy in the middle of a section. Bug report 
format: Hyphenated, never capitalized. 

Abbreviation for “Not Verified' in a test reports. 

Appears as “NOT VER" in test reports. 

Bug report format: One word. 

Hyphenated: not "onscreen". 

Bug report format: Use any of the following; "...on the screen", “...in 
the lever, "...in the stage", "...in the round'. 

Describing a situation taking place anywhere on the game screen. 

Bug report format: “ on-screerf. 

Bug report format: Hyphenated, lower case. 

Bug report format: Initial caps should be used. 

A character in a sports game as opposed to user. 

Bug report format: Two words, initial caps should be used. 

A need to increase power, but not the item that provides a user with 
additional power to their character. Bug report format: Not 
hyphenated when used as a verb: “The user must power up the 
system...". 

The item in a game that actually increases a game characters power 
level. Bug report format: Hyphenated when used as a noun: "The 
character collected the power-up..." 

This is the preferred phrase over “push the buttorf. 

The button on the game machine which restarts the game from the 
beginning as if the game machine had been powered down and back 
up again. Bug report format: Button name in all caps; "button" in 
lower case. 

A section of a game with a common theme. Bug report format: 
Capitalize when referring to a specific round. Numbers must be 
typed as they appear in the game (letters or digits): Round 6, Round 
VI, Round Six. 

Bug report format: Initial caps for all words: Title Screen, Option 
Menu, and so on. 

Always in all caps. 

Bug report format: "SEGA" in all caps; "Logo" in initial caps. 

Bug report format: "SEGA" in all caps; "Standards" in initial caps. 

A section of a game with a common theme. Bug report format: 
Capitalize when referring to a specific stage. Numbers must be 
typed as they appear in the game (letters or digits): Stage 3, Stage 
III, Stage Three. 

The button on the game controller labeled “STARF. Bug report 
format: Button name in all caps; button in lower case. 

Bug report format: Hyphenated: never capitalized. 

The screen that appears and displays the name of the game when a 
game is started. Bug report format: Both words have initial caps. 

Bug report format: Hyphenated. 

The people playing/testing the game. Bug report format: Do not use 
“ player ”. (See “Player”)- 

Term in the status field a bug may carry. Bug report format: Appears 
as "VER" in test reports. 

See “Verified”. 
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How to Enter Bugs 


FileMaker Pro is the database program used in the Test Department to create 
and update test reports. All Testers use this program to enter their bugs. 


Using FileMaker Pro 

To access FileMaker Pro from any of the PC’s in the computer area, first make 
sure Windows is running. If this first sentence makes you nervous or confused, 
simply ask your Supervisor to show you the ropes on using our computers. 

Once Windows is running, double-click on the FileMaker Pro icon with the mouse 
to open FileMaker. If FileMaker is already open, click on File in the menu bar, 
then select Open. 

Note : Never use the New function under File! If you accidentally select New, 
you must click once on the Cancel button located at the right edge of the 
window, or press Esc, otherwise you will erase some part of the database. 

To open a file, move through the File menu until the desired filename appears 
(filenames are an abbreviation of the game name, and are listed alphabetically -- 
check with the Game Lead or Assistant for the correct filename). Double-click on 
the filename to open the file. When the password prompt displays, enter 
“ Tester A screen like the one in the figure on the next page should appear. 

Entering Your Bugs 

Note : The commands on the following pages are described using the 
mouse. Keyboard equivalents appear in parentheses. 
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GAME NAME 

Bug#. Class: Status: 

□ 

Date: 

□ 

Category 
Level 


R edline G enerai 


□ 

Tester 

□ 


□ 

Rev 

□ 


Description 


Redline Status: 


Done 


[R]ediined by 




jojpen Summary 


TESTERS: PLEASE NOTE THE "REDUNED BY" BOX 
AND INPUT YOUR FIRST PASS REDUNER'S NAME. 


1. The colored fields are the fields which must be filled in for each bug. 
The white fields are filled automatically by the system. In most cases, 
you won't need to change the information in them. 

2. To begin entering a new bug, click on Edit in the menu bar, and select 
New Record (Ctrl+N). 

Note : This is a very different function from New under File, which should 
never be used ! 

3. In the Class field, click once on A, B, or C, depending on the class of 
the bug you are entering. 

4. Click once in the Tester field, and enter your initials (make sure to use 
your assigned initials; see a Database Administrator for your initials 
assignment). 

5. Click once in the Category field, then select the appropriate category 
(e.g., Text, Gameplay, Comments, etc.). 

6. Click once in the Level field, then select the appropriate level (e.g., 
"General", "Level 1", "Emerald City", etc.). 

Note : Gameplay bugs must always be given a "Level". If there is no 
Level, leave this field blank. 

7. Click once in the Description field, and type in your bug. To bold or 
underline text, highlight the desired text first, then click on Format in 
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the menu bar, and select Style, then Bold (Ctrl+Shift+B) or Underline 
(Ctrl+Shift+U). 

8. When you are ready to enter another bug, repeat Steps 1 through 6. 
Please note you will not be able to enter a new record until you have 
entered information in all the colored fields. 

9. When you have finished entering your last bug, click once on the 
Redline button, located near the top of the screen. FileMaker will 
automatically find all the bugs you just entered. You must click on the 
Redline button before quitting or the Redline button will not work 
properly. 

10. When the Print menu displays, make sure the selections “Records 
being browsed” and “All” are selected, and click once on OK to print 
your bugs. 

Finding Existing Bugs - If you need to locate an existing bug for review 

or revision, simply follow these steps: 

1. To begin a find, click on Select in the menu bar, and select Find 
(Ctrl+F). 

2. Click once in the field you wish to use to perform a find (i.e., click 
once in Tester, and enter your initials, then click once in Date and 
enter the game rev's date to find all the bugs you entered for that 
rev). 

3. If you have more than one request, click on Edit in the menu bar, 
select New Request (Ctrl+N), and repeat Step 2. 

4. Once you have entered all of your find requests, click once on the 
Find button, located at the left edge of the screen. FileMaker will 
find all the bugs which match your requests. 

Printing a Found Set - To print a found set of records, follow these 

simple steps: 

1. After you have completed your find (see the previous section), click 
once on the General button, located near the top of the screen. 

2. When the print menu displays (OK and Cancel are the options), 
make sure “Records being browsed” and “All” are selected, and 
click once on OK to print the found bugs. If you choose Cancel, a 
window which reads "Print has been canceled. Do you wish to 
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continue with this script?" will appear. At this point, click once on 
the Continue button. 

The Status Area (Scrolling Through Existing Records) - The status 
area is located at the left edge of the screen. This area is used to scroll 
through pre-existing records. Below is an example of how the status area 
appears: 

Current layout 


Bookmark 

Book 

Number of the 
current record 

Number of 
records In file 

Shows whether 
records are sorted, 
unsorted, or semi-sorted 


1. To scroll through the records, click on either the top or bottom 
pages of the book with the mouse (Shift+Page Down or Ctrl+Down 
Arrow to advance to the next record, Shift+Page Up or Ctrl+Up 
Arrow to return to the previous record). 

2. To go to a specific record, click once on the "Number of the current 
record" field, located under the Book. Type the bug number you 
need to see and press Enter. 


Data Entry 


// 






1 - 


Records: 

25- 

Unsorted 


1st Pass vs. 2nd Pass vs. Done 

First Pass - Above the bug description to the right is a box with one of 
three statements in it: "1st pass", "2nd pass", or "Done". These are used 
to track the editing which has been performed on each bug. 

"1st pass" means the bug you just finished writing now needs to go to the 
Game Lead or Assistant to ensure they have the proper classification, 
format, vocabulary, and all of the other necessary information. The Game 
Lead or Assistant will make edits to the paper, and initial it to say they've 
reviewed it and then return the pages to you so you can take them directly 
to a 1st Pass Redliner. The 1st Pass Redliner will make more format 
corrections, if necessary, and return the pages to you. You must make 
the 1 st Pass edits to your bug during the same shift you find the bug. 

After you've edited your bug in the computer, you must select the 1st 
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Passers in the "Redlined by" field. This will change your bugs to “2nd 
pass”. 

Note : If you feel the Redlining changes (1st or 2nd Pass) change the 
clarity or meaning of your bug, talk with your Game Lead and 
Redliner ASAP! It is your responsibility to see your bugs are clear. 

Second Pass - "2nd Pass" means the bugs have been Redlined once, 
and now need to be looked at a second time. 2nd Pass bugs are printed 
by the Game Lead or Assistant, given to a 2nd Pass Redliner and the 2nd 
Pass changes are made by the Game Lead or Assistant. 

Since you never see the 2nd Pass edits to your bugs, you should review 
your latest bugs once they appear in the report to ensure the changes 
don't effect the meaning of your bugs. 
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Redline Procedure Overview 


All new bugs are put through a “Redlining” process to standardize them into an 
easily understood, organized form. The Redline procedure works as follows: 

1. Tester inputs bug(s), preferably at least two hours before the end of 
the shift. 

2. Tester presses the "Redline" button, and prints out his or her bugs 
for the day. 

3. Tester gives the 1 st Pass printout to the Game Lead or Assistant. 

4. The Game Lead or Assistant makes the following Redline 
corrections on the printout: 

A. Identifies duplicate bugs (the status of these bugs are then 
immediately changed to blank by the tester - so they never 
appear in a report). 

B. Identifies spurious bugs. These are immediately changed to 
Spur. 

C. Corrects all category and level assignment errors. 

D. Standardizes the capitalization/bolding/naming of all feature, 
function, and character names, titles, etc. (For example, if 
the Lead uses "Leap-Attack!' throughout the report, the 
Game Lead or Assistant should redline each occurrence of 

" leap attack!' to read "Leap-Attack') 

5. The Game Lead or Assistant initials the pages, returns them to the 
Tester for review, the Tester then gives the same pages to a 1st 
Pass Redliner. 

6. 1 st Pass Redliners edit the bugs, and give them back to the Tester. 

7. The Tester makes the changes, shows the original redlines along 
with the corrected bugs to the 1 st Passer and clicks the name of 
the 1st Passers in the "Redlined by" field for each bug. 

8. The Game Lead or Assistant then prints out all 2nd Pass bugs. 

9. The Game Lead or Assistant gives the 2nd Pass printout to a 2nd 
Pass Redliner. 

10. The 2nd Pass Redliner edits the bugs and gives them back to the 
Game Lead or Assistant. 

11. The Game Lead or Assistant makes the changes and then enters 
the 2nd Passer's name for those bugs. 
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The Hours Sheet 

This chapter illustrates how to properly fill out the all-important daily Hours 
Sheet. You must clearly understand this procedure if you are to be properly paid 
for the hours you worked. 


The Hours Sheet 

All Testers are provided the following Hours Sheet, which must be filled out at 
the end of their shift. 


NAME: John Smith INITIALS: JS 


Date 

Game 

Platform 

Activity 

Rev. Date 

Ver. 

Hours 

2/1/94 

Sonic 2 

GG 

IP 

2/1/94 


4.5 

2/1/94 

Cyborg 

Gen 

2P 

1/21/94 


3 


Date: The day's date. 

Game: The title of the game being tested. 

Platform: Write down one of the following under the “Platform” 

column: 

GEN (Genesis) GG (Game Gear) 

GEN PAL (European) CD (SEGA CD) 

VR (Virtual Reality) CD PAL (European) 

MARS (Super Genesis 32X) SAT (Saturn) 

MISC. (Miscellaneous)* 

* = See the Miscellaneous Activities section. 

Activity: Write down one of the following under the “Activity” column: 

1P (One player) 2P (Two players) 

1P AC (Address Checker) 2P AC (Address Checker) 
REP (Working on Report) ADM. (Admin. Work) 

Note : If none of the above describes your duty, see 

Miscellaneous Activities below. 


Rev. Date: Revision date of the game being tested. 

Ver.: The letter, if any, of the version. 

Hours: The amount of hours spent performing the activity listed 

under that "Activity" (not the total hours for the day). 
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Miscellaneous Activities - If something other than testing has been 
done, enter MISC. under the “Platform” column, and add one of the 
following codes under the “Activity” column: 
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Activity 

Worked on a memo, attended a meeting, or any 
administrative duty: 

Cleaned EPROMs: 

Co-designed a game: 

Evaluated a third party or other company game or 
hardware: 

Made a videotape: 

Reviewed a manual: 

Demonstrated a game: 

Marketing miscellaneous (screen shots, etc.) 
for a game not in test: 

Did odd things (shredded paper, attended a party, 
and so on) 


Code 


Admin. - <describe duty> 

EPROM 

Test Co/De - cname of game> 

Eval. - cname of game> 

Video - cname of game> 
Manual - cname of game> 
Demo - cname of game> 

MKT. 

cdescribe duty> 


Hour Report Etiquette - Under “Initials”, write the same initials used when 
entering bugs. For example, Vince Nason’s initials are “vn”, while Vy Nong’s are 
“vy”. 


Everything related to the testing of a game must be given a “Rev. Date”, and 
don't leave any columns blank if you can help it. 
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The SEGA Address Checker 


Don’t get the wrong idea, this chapter is not going to introduce a new and _ 
miraculous technology which allows you to find out where someone lives. The 
Address Checker is actually a stack of circuit boards with a tower attachment 
which looks like this: 



LCD Display 


Indicator lights 

Switch A 
AC 

(DO NOT put power 
in here.) 


Before you begin testing, make sure Switch A (see diagram) is in the far-right 
position, and the dip switches are set as follows: 


For a Genesis title 

Switch 

Position 

1 

OFF (switch down) 

2 

ON (switch up) 

3 

N/A 

4 

N/A 


For a CD title 

Switch 

Position 

1 

OFF (switch down) 

2 

ON (switch up) 

3 

OFF 

4 

OFF 


Note : For CD address checking, the dip switches on the CD Address Checker 
tower must all be set to OFF. 

Once you’ve done that, follow these steps when you are address checking. 

When an Address Error occurs, the game will freeze, and a number, letter, or 
blank will appear in each of the LCD display boxes. Also the decimal points may 
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be illuminated in the LCD boxes. This is the Address Error, and is one of three 
sets of numbers which need to be written down. The following explains how: 

1. Record all Address Error data, being sure to specify between lower 
and upper case, and include any decimal points which accompany the 
numbers or letters. 

Note : Be certain to distinguish between "b", "6" and the ”8". 

2. Check the three indicator lights on the right-hand side of the board; 
write a “0” if a light is off, “1” if it is on. For example, if the left and right 
lights are on and the center light is off, you would write "101". 

3. Press Button 1 to display a new series of information. These are the 
Data Numbers. 

4. Repeat Step 1. 

5. Press Button 2 to display a third series of data. These are the PC 
numbers. 

6. Repeat Step 1. 

7. Press Button 1 and Button 2 simultaneously to continue with the game. 

Note : For directions on how to write an Address Error bug, refer to the 
Address Error section in the How to Write a Bug section. 

The Address Checkers take one three-prong power cord and don’t require 
any of the standard AC power supplies to be plugged into either the tower 
or the base. The dip switches on the circuit board all be set to OFF. The 
cartridges should be inserted so that they are facing the opposite direction 
as the tower. Remember, all bugs found or verified on the address 
checker must have a note stating that the bug was found with an AC. 
These bugs must be rechecked with a regular Genesis to ensure they are 
valid. 

See, simple as pie! Happy address checking! 
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A Final Word 

Before unleashing you on the world of testing, here are a few final guidelines 
and, in some cases, reminders which must be obeyed while you work. 


A Day in the Life of a SEGA Tester 

A typical SEGA Tester’s day includes, but is not limited to, the following: 

Upon arriving: 

1. Sign in on the time sheet. 

2. Check the board for your assignment. 

3. Get your game, current report, and any assigned tasks from the 
respective Game Lead or Assistant. 

4. Prepare a video tape, notepad, and a writing utensil for action. 

5. Do the assignment. 

Before leaving (or changing games): 

1. Enter new bugs into the report. 

2. Print out new bugs. 

3. Deliver your Test Report with your name, all VER., NOT VER.’s 
and tick marks to the Game Lead or Assistant. Also hand in 
your Test Plan sheets. 

4. Have all bugs 1st Passed, edited, and clicked to 2nd Pass. 

5. Update your Hours Sheet and leave it in the hours log bin. 

6. Sign out on the Time Sheet. 

7. Fill out your Pay Hours Sheet. 

Lunches - In return for working a full day of test on a weekend, the 
department will buy a morning snack and lunch for the crew on that 
particular day. This a privilege the Supervisors and Test Manager have 
decided to give weekend Testers. 

During the week, if you are on a business lunch (taken out by a producer, 
for example), indicate you took your normal lunch time (half hour), and 
mark the remaining time as work. This way you'll be credited with normal 
work hours while you discussed business outside of the office. 

A Few Simple Do’s and Don’ts - All Testers are expected to follow a few 
simple guidelines which will make everybody’s job easier. Keep the 
following Do’s and Don’ts in mind and you should be well on your way to 
making Sega Testing history! 
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Do... 

• Leave a clean station before going home. 

• Keep your daily Hours Sheet up to date. 

• Videotape at all times. 

• Write accurate notes and bugs. 

• Check your bugs meaning after they are second-passed. 

• Return borrowed equipment to the proper station. 

• Take your half-hour lunch between 11:30 and 1 ‘.00 for the day 
shift, and 6:30 and 8:00 for the night shift. 

• Take one ten minute break before lunch and one ten minute 
break after lunch. 

• Let your Supervisor know you will be late, before you are late. 

• Let your Supervisor know you will need to leave early, the day 
before you need to leave. 

• Talk with the Supervisor or Test Manager if you have questions 
or issues. 

Don’t... 

• Get talked out of bugs by Producers. 
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